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ABSTRACT 


Over the last two decades, cockpits have migrated from 





the traditional analog gauges of moving dials to computer 
displays representing an assortment of flight data. To keep 
in stride with this modernization trend, the U.S. Navy 


determined that the newest rotary-wing fleet aircraft, the 








MH-60S and MH-60R, would incorporate these advanced cockpit 
designs. This program was named Common Cockpit. Using 
structured interviews with current Navy MH-60S pilots, and 
analysis of system design models; it was determined that the 


MH-60 glass cockpit has fundamental flaws in cockpit design 





and usability. One major issue identified is the omission 


of a fully integrated moving map. The lack of a moving map 





is a serious issue because many of the MH-60 missions 





requir precis navigation. The Navy pilots interviewed 





indicated that lack of a moving map makes mission task 





performance difficult and could threaten safety. It is 
argued here that a user-centered design methodology would 


have given ample consideration to including the moving map 





and would have produced a mor ffective and usable cockpit 


design. Recommendations are made to improve design 





methodology by using Crew-Centered Design methods. 
Recommendations are made regarding modification of existing 


Common Cockpit acquisitions procedures needed to produce a 





better product for the fleet. 
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I. INTRODUCTION 


A. PURPOSE 


This thesis will accomplish three fundamental tasks: 


Using structured interview methods, usability 





engineering techniques and the author’s personal 





xpertise, determin if there are any existing 
design or usability issues with the MH-60S Common 


Cockpit 





In regard to these existing design issues, review 
the methodology under which the design was created 
and recommend a different or modified methodology 
that would create a better design. Using this 
recommended design methodology, present a 


description of one potential design improvement. 








In the scope of the Common Cockpit acquisitions 
process, recommend changes to said process that 
would enable a better cockpit to be designed and 


acquired. 


B. BACKGROUND 


The author’s first experience with piloting an aircraft 





came formally in the spring of 1994. It was at Whiting 


Field, 


Pensacola, Florida, where he was first introduced to 





the complexities and challenges of piloting an aircraft. 


Following the standard training track, he started with the 


basic single-engine turbo-prop T-34. Following the fleet 








helicopter replacement pipeline, h then flew the basic 


helicopter trainer, the TH-57. Basic flight training was 


followed by training and operational missions in the fleet 











helicopter H-46D Seaknight, where he accrued almost 1,000 


flight hours. This tour was followed by extensive 





experience in two more fleet aircraft: the H-3 Sea King 





helicopter and the twin-engine fixed-wing utility transport 





C-12B Huron. His most recent tour was in yet another fleet 








helicopter, the MH-60S Knighthawk. 


Unique to the Knighthawk and a substantial departure 


from previous aircraft was the use of an all-digital “glass” 








cockpit. Simply put, the traditional analog dials, gauges 








and switches of the previous generation of aircraft have 








been replaced with four LCD monitors and a host of keypads 


and other more “computer interface” oriented input devices. 


To the author, the potential of this transition was 





exciting. Having seen computers explosively grow in both 








functionality and usability since first being exposed to the 


Radio Shack TRS-80 and Commodore 64 in the mid-1980s, the 





author assumed that a 21°* century cockpit must have the 


functionality of any top computing system and the usability 





of the sleekest operating system. He imagined a cockpit 


where th feel was more like the bridge of the Starship 








Enterprise than the cockpits of the previous generation of 
aircraft he had flown. The expectation was that everything 


was configurable, selectable, scalable, and absolutely user- 





friendly. Those lofty expectations were not quite met. 


The author encountered a cockpit that did indeed have 





some of these features, but in many aspects seemed lacking. 








To the author and his fellow squadron pilots, there seemed 


to be something fundamentally lacking in the usability of 





2 


the cockpit itself. Too often, particularly with new 








pilots, the cockpit seemed a jumbled collection of buttons 





and computer menus. It was clear that usability had taken a 





back seat to functionality during design. How could this 


have happened in the Navy’s newest cockpit? 


Following his tour in the Knighthawk, the author opted 
to explore the science behind the computers that drove that 





cockpit. While studying Computer Science at the Naval 


Postgraduate School, he was exposed to the concepts of Human 





Computer Interfaces. Armed with knowledge, he arrived at 


the purpose of this thesis. 


Cc. PROBLEM DEFINITION 


Based on informal user interviews and personal 





xperience, the MH-60S cockpit has fundamental user design 











and usability issues that potentially impact mission 


accomplishment. The question is thus: Will the use of a 








more Human Systems Integration (HST) oriented design 


methodology, applied to the same functional requirements as 

















outlined in MH-60S Operational Requirements Document (ORD), 


produce a more usable result? 


Also, can this design methodology be applied throughout 
the acquisitions process in order to not only enhance 


cockpit usability but all human-machine usability? 
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II. A REVIEW OF THE MH-60S AND COMMON COCKPIT 
IN RELATION TO THE ACQUISITIONS PROCESS 


A. COMPUTER EVOLUTION AND COCKPIT INTEGRATION 


The last 20 years of aircraft design and development 
has seen a revolution of sorts. As computers emerged from 
the large units, common in the 1950s, to the sleek, light 
and low-power units of today, they have also slowly made 
their way into the aircraft. Today’s modern computer- 
integrated or “glass” cockpits almost resemble a computer 


work station more than a traditional cockpit. 


B. HELICOPTERS AT SEA 


Of military fleets in the world, the need to conduct 





sustained operations at sea is the backbone of power 








projection. In this effort of sustainment, logistics is the 





key. Fleet logistics is, of course, a little more 








complicated than traditional land logistics since everything 





has to be delivered to ships, which prefer to be at sea. 





One method of doing this is via a delivery technique called 


Vertical Replenishment (VERTREP). This supply delivery 





procedure involves transferring goods and people from one 
ship to another, shore to ship or ship to shore, by either 


attaching an external load to a helicopter or via an 





internal transfer. For years, this mission was filled by 


the versatile H-46D Sea Knight (Figure 1). 








Figure l. CH-46D Sea Knight was eventually replaced by 
the MH-60S (From: [1]). 





Although the aircraft was initially intended as a 





logistics platform, as time progressed and the needs of the 





fleet became more varied, the Sea Knight’s mission set 





expanded to include Search and Rescue (SAR), Visit Board 
Search and Seizure (VBSS) and some limited Special 


Operations (SPECOPS). 


By the early 1990s, two things quickly became readily 





apparent to Navy planners: the Sea Knight was rapidly 





exceeding its life expectancy, and the continued growth of 





mission sets was pushing the limits of the airframe. It was 
time for a replacement. The answer came in the form of the 


Sikorsky MH-60S (Figure 2). 





Figure 2. MH-60S Knighthawk doing VERTREP duties (From: 
[2]). 
Cc. MH-60S PROGRAM 
1. General Description 


The MH-60S is an all-weather multi-mission helicopter 
built as an amalgam of UH-60 Blackhawk and SH-60 Seahawk 
components. First deployed in January 2003, the MH-60 


Knighthawk is designed to conduct a varied mission suite 








including Airborne Mine Countermeasures (AMCM), Logistics 
(LOG) and a more aggressive mission known as Combat Search 
and Rescue (CSAR, also known as Armed Helo or AH) [14]. 


Characteristics are summarized in Table 1. 


Dimensions: 


Main Rotor Diameter 

Tail Rotor Diameter 
Overall Length With Rotors 
Turning 


Height to Top of Turning 


Length of Fuselage 
Cabin Volume 


2 x GE T700-GE-401C turboshaft engines 
1,260kW each 


Maximum Cruise Speed 263km/h 





Never-Exceed Speed 333km/h 
Table l. MH-60S Characteristics (From: [14]). 
2. Program History 


The MH-60S was born out of a recognized need in the 


early 1990s to replace several aging helicopter platforms. 





By the end of the cold war, the Navy was operating eight 


types of helicopters [17]. All were specialized for 





different missions, including Vertical Replenishment 
(VERTREP) and logistics (LOG), Anti-Submarine Warfare (ASW), 
Combat Search and Rescue (CSAR) and Naval Special Warfare 


(NSW) [4]. Of the fleet helicopters, the H-1N, H-3 and H-46 





and HH-60H were either very near or approaching the end of 





their service lives [18]. 


Conventional naval rotary-wing aviation urban legend 
holds that around this time, seeing an opportunity to reduce 


operating costs and increase mission flexibility, the Navy 
8 





initiated a program that would pare down the existing 
diverse helicopter fleet to just two variants of the 


Sikorsky H-60 (Figure 3). As this section will chronicle, 





this simple interpretation of history is not quite the case. 







HELO MASTER PLAN Jou = CONOPS 


HSL - ASW/SUW. 





ROMEO-CVW : 
DD, DDG, CG, FFG ASW/SUW 
(CV(N), DD, DDG, CG, FFG) 
HS - ASW/SAR ROMEO-Expeditionary 
CV(N) ASW/SUW 


(DD, DDG, CG, FFG) 
MH-60R 






HC/VC - VIP/VOD/SAR 
Shore 
HC —- VERTREP/SAR 
_| CLF, LHD/A SIERRA-CVW: 
SUW/CSAR/NSW/OAMCMI/AA 
(CV(N), CLF) 






HS — CSAR/SPECWAR/AA 
CV(N) 





SIERRA-Expeditionary: 
SUW,NSW,SAR,OAMCM 


MH-60S (LHD/A) 
SAR (Station Support 
ae — 


re ‘IN Master Plan’s next evolutionary step 
Aligns Helo warfighting organization 
Force Structure 

Based on warfighting capability 





. aan ae St ckegy-tintuniee TMS from 6 to 2 
+ Helo Force Structure unchanged 


Figure 3. The Helo Master Plan (From: [3]). 


The CH-60, as the MH-60S was originally known, had it 
roots in the late 1980s and early 1990s discussions 
revolving around the Marine Corps vertical Medium Lift 


Replacement (MLR) project [19]. At the time, the Marine 





Corps was funding the development of the Boeing MV-22 medium 


lift tilt rotor to replace its aging CH-46E medium lift 





helicopter fleet. While Secretary of Defense under 





President George H.W. Bush, Mr. Dick Cheney attempted to 


terminate the V-22 program due to cost overruns. His 


solution to the MLR was the Sikorsky CH-60 [19]. 


After a protracted battle, the Marine Corps eventually 





won and continued its plan to acquire the MV-22. Sikorsky, 


however, continued to shop its CH-60 to all four services 


[20]. 





In specific reference to the Navy portion of the 


Sikorsky proposal, Inside the Army writes: 


As for the Navy, Sikorsky contends the service's 
fleet support helicopter assets "are aging and 
experiencing accelerated attrition." The Navy has 
some recapitalization plans in place -- such as 
an upgrade to its fleet of CH-46s and procurement 
of a new helicopter beginning in FY-98 -- but 
Sikorsky anticipates an upcoming cost and 
operational ffectiveness analysis will "have 
difficulty dealing with the cost ffectiveness" 
of them. [20] 




















Inside the Army continues: 


Some observers theorize that the Sikorsky 
proposal is merely an effort to stave off a halt 
in the Black Hawk production line should the 
Office of the Secretary of Defense not give the 
Army additional money for Black Hawk procurement 
in FY-97. [20] 








By 1996, Sikorsky had grown desperate to push the CH-60 


multi-service program, or at the very least extend the 


manufacture of Army UH-60 Black Hawk program [21]. They 





felt 





their life depended on it: 


There is trouble down the road [for Sikorsky],a 











company official said last week. "Without Black 
Hawk procurement, it would be difficult for 
Sikorsky to continue as a company." He added that 
Black Hawk procurement could total as much as 
S1.1 billion over the next five years. "And 
right now Sea Hawk production has stopped and the 
CH-53 procurement is not significant," he 
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continued, “and there really is no future program 
except the [SH-60R] . . . so, no, there's not a 
lot of business right now for Sikorsky. The 
draft briefing charts prepared by the Program 
Analysis and Evaluation shop state flatly that 
the ‘Cancellation of  UH-60 buys may affect 
Sikorsky's survival, and has cost implications 
for the Army's RAH-66 Comanche.’ [21] 














The Army had originally planned to buy 36 Black Hawk 





helicopters per year during fiscal years 1998-2003 but had 











shifted these monies to other priorities [21]. 


This mess quickly drew in the Marine Corps again, this 


time in their effort to update the UH-I1N. The original 





Marine plan was to update both the UH-1 and AH-1 to the N 
and W models, respectively. This upgrade would leverage an 
already existing training and supply system while upgrading 


the cockpits and engine/rotor combination [22]. The Office 





of the Sectary of Defense (OSD), headed by Mr. William 











Perry, however, wanted to keep the Sikorsky production lines 
open and continued to push the CH-60 as an alternative to 


the -UH=L. 


Angered by the Army’s move to halt UH-60 Black Hawk 





production, the OSD drafted a plan to take the almost $1 





billion originally scheduled for the UH-60 and give it to 





the Navy or Marine Corps to fund the CH-60, a predominately 
Black Hawk variant. The Marines balked yet again, 
preferring to stick with their original upgrade plans for 


the Cobra and Huey [23]. 


The Navy, however, saw an opportunity to solve several 


of their helicopter problems with one solution. Starting in 





1995, the Navy starting drafting the “Navy Helo Master Plan” 





(HMP) [4]. The HMP morphed out of a Center for Naval 
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Analysis (CNA) study that looked at the Navy’s helicopter 


force structure and what would be required to transition to 





the future. The initial HMP roadmap didn’t include the CH- 
60 (Figure 4) but, once word of a potential “free” Black 
Hawk variant was out, the plan was quickly revised (Figure 
5). The H-60B/F airframe that was currently in use was not 


considered since that particular production line had already 





been shuttered. The replacement for the H-60B/F, named the 
MH-60R was also not considered since that production line 


wasn’t scheduled to start running until early in first 





decade of 2000 and would do nothing to keep the Blackhawk 
line open. This move to “give” the Navy a “free” airframe 


virtually locked in the CH-60 as the helicopter of choice 








for the Navy sinc th near Navy helicopter roadmap 


depended on it [24]. 
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| Helo Master Plan 


Where Are We Now: 


Current Roadmap 


SH-60B a 


SH-60F a 


42 (24 Active/18 USNR) 


HH-60H 
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21 (Misc) 
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- — — 





Figure 4. Original Helo Master Plan (From: [4]). 
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Helo Master Plan 


Proposed Roadmap 


ee oa oa a ae 


FY05 FY07 
TMS REDUCTION: SH-60B/SH-60F/HH-60H/CH-46D/SH-3/SH-2G/UH-1N 





Figure 5. Revised Helo Master Plan based on the CH-60 
acquisition (From: [4]). 


The HMP momentum resulted in a sole source Request For 





Proposal (RFP) for Sikorsky being issued in 1996 [24]. In 
fiscal year (FY) 1997, Congress directed Sikorsky Aircraft 
(SAC) to produce a demonstration aircraft [25]. This 
Operational Assessment (OA) demonstrator was a combination 


of the existing UH-60L Blackhawk airframe with H-60 Seahawk 





components [26]. Between November 1997 and January 1998, a 
successful Operational Assessment (OA) directed by 
Commander, Operational Test and Evaluation Force (COTF) was 


conducted [25]. This success led to the program receiving a 














Mile Stone (MSTT) (Milestone B equivalent)/Low Rate 




















Initial Production (LRIP) go-ahead decision in July 1998 and 





Sikorsky being named as the sole source contractor on 
October 6, 1998. The contract was under the existing U.S. 
Army Aviation & Missile Command, Redstone Arsenal as the 
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contracting activity [27]. It should be noted that during 


the OA, “Neither approved nor signature-ready ORD 





(Operational Requirements Document) or TEMP (Test and 








Evaluation Master Plan) documents were available during the 
November 1997-January 1998 OA period” [28, p. 2] and draft 


documents were used as a guideline. 











Designated an Acquisitions Category IC (ACAT IC) 








program by the Under Sectary of Defense for Acquisition, 





Technology & Logistics (USD(AT&L)) in July of 1998 [25], the 
program quickly ramped up. The all new production CH-60S 
first flight followed in January 2000 [14], [29]. The CH- 
60S was quickly re-designated the MH-60S to reflect the 


multi-mission capability of the airframe [14]. Three 











distinct mission sets were designed in and called “blocks”. 

















Block I reflected th general logistics mission, block 








was modified to conduct Airborne Mine Countermeasures (AMCM) 




















and block incorporated the more offense Armed Helo (AH) 
mission kits [7]. By FY 2008, 132 airframes had either been 
ordered or fielded to Navy squadrons. The current plans 
call for a total of 237 [14]. 








D. THE COMMON COCKPIT 


1. History 


As the new CH-60 started production and the planned MH- 





60R (scheduled for production in 2000 [21] firmed up, the 
Navy decided to make the technological leap to an all 


digital, or “glass,” cockpit display for both the MH-60S and 





MH-60R helicopters. This cockpit, designed for use on both 
airframes to enhance commonality [29], was named the Common 


Cockpit (CC). At this point, the CC was notional and lacked 
IeS 





any specific ORD type document of its own. At this point 
the MH-60R was the more mature of the two programs and thus 


it can be concluded that initial efforts for the CC were 





applied toward MH-60R functional requirements. 








Initially included as part of the MH-60S Operational 








Requirements Document (ORD) [30] as well as the MH-60R ORD, 





the CC was spun-off as an “845” contact prior to 2002 [31]. 





An 845 contract referrers to “10 U.S.C. 2371, Section 845, 
Authority to Carry Out Certain Prototype Projects.” [32] 
Per the OT Guide: 


Other “Transactions” for prototype projects are 
acquisition instruments that generally are not 
subject to the federal laws and regulations 
governing procurement contracts. As such, they 
are not required to comply with the Federal 
Acquisition Regulation (FAR), its supplements, or 
laws that are limited in applicability to 
procurement contracts. BZ Pi" 28.) 











Due to its designation as an 845 program, funding, 








particularly Research and Development (R&D) costs, are 





difficult to define. According to [33], Lockheed Martin was 
awarded a $423 million contract to produce common cockpits 


for the MH-60S and MH-6OR. This amount, however, may not 





include R&D costs, since this is a production (APN-1) 
contract and usually does not include research and 
development costs. For certain, prior to the contract 


award, $70.53 million had been spent, at least in part, on 








R&D [34]. Other R&D costs may be included in the Sierra and 





Romeo development costs but are not clearly defined [35]. 


CC requirements are also scattered throughout the 








Sierra and Romeo ORDs and hard to concisely determine. As 
an initially cobbled-together program, the CC currently 
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lacks a clearly defined requirements document such as the 
MH-60S ORD. As of this writing, however, there is a push to 


formalize these requirements [35], [36]. 





2. Description 


The Common Cockpit (Figure 6) is made up of several 





components including Multi-Function Displays (MFD), Fixed- 





Function Keys (FFR) (Figure 7) and Programmable Key 


Interface (PKI). 
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Figure 6. MH-60S Block I Common Cockpit (From: [5]). 
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Figure 7. PKI / FFK located in the lower consol area 
the CC (From: [5]). 

According to [14]: 

The CC includes four 8in x 10in active matrix 
liquid crystal displays and dual programmable 
operator keysets. The avionics includes dual 
flight management computers and an audio 
management computer. The navigation suite 
includes a Northrop Grumman (Litton) LN-100G dual 


embedded global positioning 
navigation system. 
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IIIT. INTERVIEW METHODOLOGY 


Based on an in-depth knowledge of the subjects by the 


author, himself an experienced U.S. Navy pilot, a structured 





interview method was chosen to obtain needed U.S. Navy Fleet 


pilot inputs on the MH-60 design. The interview method 





selected is based on several considerations as described in 





[15, p. 9] and elaborated below. Interview data is 
summarized in Appendix A. Raw interview data is found in 


Appendix B. 


A. INTERVIEW SUBJECTS AND PROCEDURES 





Nine subjects were interviewed over a three-day period 
from October 27, 2008, to October 29, 2008. Subjects were 
all pilots from the MH-60S West Coast Fleet Replacement 








Squadron, Helicopter Sea Combat Squadron 11 stationed at 








Naval Air Station, North Island, San Diego, California. 


Eight of the subjects were instructor pilots and one was a 








student pilot nearing the end of the training syllabus. 
Pilot experience is summarized in Table 2. Of nine subjects 
interviewed two were qualified Helicopter Aircraft Commander 


(HAC) in a different aircraft model. Table 2 summarizes 





subject flight hour and experience levels. 
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Total Total MH- Se hs 

oat a eos Bile Fares 

Aircraft 
1200 30 Yes 
1200 1000 No 
1370 250 Yes 
1300 1000 No 
1450 1200 No 
275 100 No 
1550 1350 No 
1250 1000 No 
1300 900 No 

Table 2. Subject summary data. 








Interviews were conducted in a HSC-11 briefing room 


well known to all nine subjects. All interviews were 





conducted during normal working hours (0800-1500). 
Questions were formulated by the author based on his expert 
knowledge as an aviator and was tailored to efficiently 


capture not only subject facts, opinions, attitudes and 





answers but also the reasoning behind the answer. In short, 





the author based the interview questions on what he thought 


would make sense if he were in the subject’s position. The 








complete Interview Summary in Appendix A and raw interview 








notes are found in Appendix B. 


B. INTERVIEW METHODOLOGY RATIONAL 








The primary interview consideration in regard to the 





subject pool was an attempt to get a somewhat representative 


picture from all fleet squadrons. There are currently seven 














squadrons flying the MH-60S. Three squadrons are located in 








San Diego, CA, three in Norfolk, VA, and one in Guam. 


Mission sets for each squadron vary depending on the 











deployment and are not equally distributed throughout the 
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squadrons. Thus a pilot of one squadron may encounter 
Significant different operating conditions of another pilot 


in another squadron. The pilot population of each squadron 








is roughly 40. In total, there are roughly 280 active MH- 
60S pilots in the fleet at any one time, all with different 











skill sets and mission experiences. It should be noted that 
all pilots initially train to the same skill sets in the 
FRS. Squadrons, based on their operating requirements, may 


perform these mission sets more or less frequently. For 





example, HSC-25 in Guam is the primary SAR asset for the 








Northern Marinas Islands. Thus, it prosecutes significantly 





more search and rescues than her sister squadrons in the 
continental United States, where the Coast Guard has primary 


SAR responsibilities. 





With this diversity in squadrons in mind, HSC-3, the 





West Coast MH-60S Fleet Replacement Squadron (FRS) was 





chosen. Instructors are comprised of a mix of aviators from 
all the HSC fleet squadrons, thus ensuring a singular point 
of view of a particular squadron experience or geographic 


area would not b represented xclusively. The FRS 





instructor pilot pool offered the unique advantage of 





collecting the most skilled pilots throughout the HSC 


community and depositing them in one centralized location. 





Mission diversification among interview subjects is 





summarized in Table 3. 
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Mission Number of Pilots 
SAR 7 
NSW/TACTICS 5 
FAM 7 
MEDEVAC 2 
AH iS} 
Table 3. Mission experience among interview subjects. 
Subjects are often familiar with more than one mission 
area. 
The audience, in this cas xperienced fleet aviators, 





was well known to and as well understood by the author (who 








was also the interviewer). As indicated, the author is also 
an experienced fleet aviator, and has flown the same 
model/type/series as the interview subjects. Of the several 








types of interview methods presented in [15], an informal 


in-person interview was chosen based on the advantages 





outline in Table 2. Per [15, p. 14], the author felt that 
open-ended questions, in which the key component of the 
question would be the insight that led the respondent to 


that conclusion, were of the most value for the purposes of 





this study. 


Fach interview was conducted with a written script in 











which notes were taken by the interviewer (Appendix A). The 
subjects were familiar with their particular cockpit 


environment, but were unfamiliar with certain Human Cockpit 








Interface (HCI) terminology and concepts. The author felt 








that if the subjects had a better understanding of different 





interface options, a more frank and revealing discussion 


would be the result. 
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Finally, following guidelines established in Table 4, a 


quiet, private 





interview room was used. In this case it was 





a briefing space which the pilots were both familiar with 


and provided convenient access as it was located in the 








squadron spaces. Based on th xperienc of the 


interviewer, pilots are relaxed and more open to discussion 





in a familiar environment. 





Characteristics 





Done with a written script 





Advantages 


Can explore answers with respondents 


Can assist respondents with unfamiliar 


words and concepts 





Special Needs 








Requires a quiet area to conduct’ the 


interviews 








Table 4. In-person informal interview attributes (After: 


[15]). 
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IV. INTERVIEW RESULTS AND DISCUSSION 


A. INTERVIEW RESULTS SUMMARY 


Th 
necessarily lend itself to easily quantifiable summary data 


as the bulk of the information is pilot comments about 

















interview method described in Chapter does not 














particular systems or cockpit tasks. These comments did 





tend to group in to several general areas of interest. 


Topics were: 





All nine subjects expressed the need for a MFD 


integrated moving map to aide in performing critical 





navigation tasks and for maintaining adequate 


Situational awareness across th ntire spectrum of 








missions. Eight of nine interviewees had some 





experience with the Digital Map Kneeboard (discussed 


in Chapter V) which was developed independently from 





the cockpit instrument suite. Interviewees stated 





that the kneeboard device was a poor substitute for 
a fully integrated moving map. Pilots believed that 
use of the knee board version was cumbersome and 


presented a significant disruption to their normal 








scan pattern. They all stated that integrating the 





functionality of the DMK in to the Multi-Function 








Display (MFD) would be the optimal solution based on 





their aviation experiences with cockpit scan 
patterns and the elimination of the distractions 
caused by “head-down” cockpit tasks. The negative 
effects of this type of cockpit activity will be 


discussed in Chapter V. 
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e Five of nine subjects expressed dissatisfaction with 


the current implementation of the Forward Looking 





Infrared (FLIR). 





e Four of nine subjects felt the current Programmable 








Key Interface (PKI)/Fixed Function Key (FFK) user 


interface was difficult to use. 





e Four of nine subjects felt there were readability 


issues with various aspects of the digital flight 





and malfunction indication displays. 





A more in-depth summary is outlined in Appendix A, and 


raw interview data is found in Appendix B. 


B. GENERAL INTERVIEW DISCUSSION 








The interview process was revealing to say the least. 
Topics ranged from display symbology color to menu depth. A 


more detailed summary of these topics ar presented in 





Appendix A. With every subject, however, th interview 





quickly turned to the issue of geo-referencing the aircraft 


during missions. Of the eight subjects familiar with the 








DMK, all eight stated that the usability of a moving map 





would be greatly enhanced if it was implemented on the MFD 








instead of the DMK. Two subjects recommended replacing the 








center back-up instruments and replacing it with a fifth MFD 











used solely for geo-positioning while another requested 


robust viewing options including ego and exocentric views. 








In the course of the interview process, it became very 





clear to the author that this thesis would not be a simple 





or straightforward usability analysis on an existing cockpit 





function or task. 


28 


The focus of this thesis quickly turned to = an 
exploration as to why user expectations were not met in the 
MH- 60 aircraft regarding the incorporation of a mission 


critical information display (specifically, the need for a 





MFD moving map). The author then set out to answer the 
question of how the U.S. Navy pilots could be so grossly 
under-serviced and how this problem could be rectified in 
future acquisitions projects. To that end, the remainder of 


this thesis will focus on the issues surrounding the design 





methodology used during the MH-60 development, and dedicate 
efforts toward ascertaining what went wrong and how aircraft 
system design and acquisition methods could be improved. We 
will first begin with the discussion of the importance of 


moving maps. 


Cc. SPECIFIC DISCUSSION ON MOVING MAPS 


One item of particular interest was a theme for which 


all nine subjects expressed as a concern: the need for a 





usable moving map. Seven subjects directly commented that 





the current implementation of this functionality, the 





Digital Map Kneeboard (DMK) was not a practical solution due 





to usability issues and was thus not used. One of those 





that did not comment on the usability of the DMK had never 





used the device and the other thought it was a useful 





Situational awareness tool for non-pilot aircrew in the 


back. The drawbacks of the kneeboard DMK solution will be 








explored in Chapter V. 


Regardless of the mission, all nine subjects stated 
that some form of a map, or a way for the pilot to maintain 


geographic situational awareness, was a must to keep the 
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pilots from cognitive overload given the complexity of the 
missions they were flying. This will be further discussed 


below. 
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V. MOVING MAPS AND THE COMMON COCKPIT DESIGN 
METHODOLOGY 


A. MOVING MAP RATIONAL 


Before discussing a moving map specific to the Common 


Cockpit, a discussion on the generalities of moving maps is 





warranted. 


ZL: Moving Maps 


In general, moving maps all provide the same 








information: a representation of the relationship between 
the location of the user and a specific geographic area in 


which the user is located. As the user’s position changes, 





the map adjusts to keep the user’s geospatial position and 








thus geospatial awareness accurate. 


The benefits of moving maps as an enhancement to 





Situational awareness in general are well understood by both 





government and private agencies and will not be discussed in 


this paper. This paper will specifically discuss moving 





maps in relation to general U.S. military flight profiles. 





The U.S. military recognized the need for a moving map 





as far back as 1979. The first digital map was created by 
Harris Corporation for the U.S. Air Force F-117 Nighthawk. 
Since then, moving maps have been installed by several 
different companies on aircraft, such as the C-130, F-16, 


F/A-18, AH-12, UH-1Y and the AH-64, to name a few [37]. 


MH-60S and MH-60R mission sets were briefly outlines in 

















Chapter ‘ n review, the missions vary for purely over 





water actions including Anti-Submarine Warfare (ASW) to 
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overland missions such as Combat Search and Rescue (CSAR or 


AH). From the author’s experience, seldom do these missions 





cover exclusively one type of geography over another, but 





instead start in one geographic region and end in another. 





This can be attributed to the fact that Navy helicopters are 
often ship-based but work in the littorals. Even in the 
case of open water operations, artificial boundaries are 
instantiated by naval battle groups to de-conflict 
dissimilar operations. An example of this would be ensuring 


low-flying aircraft such as helicopters do not inadvertently 





wander in the carrier landing pattern of much faster fixed- 
wing aircraft. Even purely ASW work requires to some extent 


knowledge of sea bottom topography. Lockheed Martin came to 





this same conclusion while analyzing the MH-60R requirements 








for the ASW mission and initiated an Independent Research 








and Development (IRAD) project to explore possible 








implementations [38]. 


Generally, from the author’s experience, a sizable 


portion of Navy flying is either overland or in close 





proximity to some form of land mass or relevant geographical 


partitioning. This may include international maritime 





boarders as well as designated “restricted” areas where 


entry would violate national or international flight 








regulations. Thus, one should conclude that geographical 





Situational awareness is applicable to both overland and 





oversea mission sets and is thus entirely applicable to the 





MH-60S and MH-60R and their associated missions. 
2. Moving Map MH-60S Implementation 
With the corporate understanding of the benefits of 


moving maps prevalent in the helicopter community and 
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aviation in general, the question is begged on how did a 
moving map get overlooked in the original common cockpit 


design process? 


Prior to [30], the U.S. Navy never specifically 


identified a moving map solution to navigation and other 








functional requirements defined in the ORD. This has the 
potential to make a coherent human-cockpit interface design 


difficult and recommendations on this approach will be 





discussed later. Sprinkled throughout the ORD were numerous 
requirements to display some type of geo-spatial information 


to the crew. For example, section 4.2.1.1, in discussing 











the Airborne Mine Counter Measures (AMCM) functional 





requirements states the following: 


A precise helicopter AMCM minefield navigation 
system is required to accurately determine, 
display, record and report geo-spatial position 

















of mine-like object... cockpit displays shall 
provide the capability for the aircrew to 
maneuver the helicopter along a desired/selected 
track. [30] 





Consideration was given to an integrated moving map for 
the Common Cockpit prior to [30]. Tasked by the Navy, Naval 
Research Laboratory did discuss the need for an integrated 
moving map for the MH-60S in 2001. Although the initial 


plan was to implement the first MH-60S moving map to support 





the CSAR mission, the major thrust of the program was to 
help support the ASW and MCM mission [39]. The push for the 
moving map was also driven by the success that moving maps 
had in providing heightened situational awareness in the 


F/A-18 Hornet and AV-8B Harrier [40]. 


Prior to production aircraft 120, the possibility of 





MFD integrated moving map was moot. The first generation of 
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the Common Cockpit included as part of its hardware a key 
computing device called the Flight Mission Computer (FMC) 


that lacked sufficient computing power to implement a moving 





map [41]. Per [5], the FMCs “are provided for information 


processing and data management. The FMCs execute Flight 








Management Program (FMP) software and provide all flight 














management functions” [5, p. VII-15-20]. Since production 





aircraft 120, however, the all FMCS in new production 





aircraft, as well as fleet aircraft, hav been replaced 





with the Mission Computer (MC), which is capable of driving 


the necessary hardware and software to utilize the hardware 





map features already located on the MFDs [41], [42]. 


Even with the temporary technical limitation posed by 





the FMC, the reason that a moving map was not an initial 





requirement in the Common Cockpit is still not completely 





clear. As discussed above, the benefits of a moving map are 





well known and would have been one of the fundamental issues 





discussed by any design team based on ORD functional 
requirements. Thus, the cockpit design methodology should 
at the least have driven the inclusion of the moving map 


requirement once technical limitations were overcome. Why 








didn’t it? One possible reason could be the cockpit design 


process used by Lockheed Martin. 


3. Lockheed Martin Cockpit Design Methodology 


According to [43], Lockheed Martin loosely followed in- 








house systems engineering design methodology titled “Process 














Guidance Series—System Engineering: Human-Computer Interface 





Requirements (HCIRS).” This methodology was more or less 
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standard throughout the industry and eventually became 





formalized as the Department of Defense Architecture 








Framework (DoDAF), Version 1.0. 








It should be noted that without a singular first-hand 





view of the entire Common Cockpit design process or clear 
documentation at every step, it is impossible to accurately 


map each individual design stage to the components of the 





Lockheed Martin methodology. Methodology is further 
obscured by the fact that exact composition of each group 
(Human Factors Engineering, Software Engineering, etc.), as 


delineated in [6], cannot be accurately determined within 





the scope of this thesis. That said, documentation provided 


by Lockheed Martin to the autho,r as well as [43], indicates 





that this methodology was generally followed. It should 


also be noted that according to [44] the specifics of human 





factors are “greatly influenced by customer requirements and 


expectations.” 


a. Lockheed Martin Process Guidance Series 
Systems Engineering: Human-Computer 
Interface Requirements (HCIRS) Overview 


Lockheed Martin’s design methodology is a systems 


engineering approach to all encompassing approach to Human 











Computer Interface (HCI). It uses a straightforward 





iterative design process for development, design and test 





implementations of HCI requirements. 


b. Systems Engineering Process 


Reference [6] is a framework to help system 





engineers develop a usable HCI for users of any type of 


computer system and is not specific EO aviation 


35 





applications. It provides “recommended contents for those 





sections of a system, subsystem, configuration item, or 








interface requirements specification used in documenting HCI 


requirements [6, p. 7]. These recommended contents are 





outlined in Figure 8. 





Function and Task Elaboration 
Accessing the Computer 
Inpat Devices 
A Devices 
3.5.1. Kinds of Output Devices 
3.5.2. CRT and Plasma Panel Screens 
Major Interface Considerations 


Question-and-answer Dialozs 
Foem-filling Dialogs 
Selection 


Menu 
Graphic Interaction 
Comamand Languages 
Query Languages 
Entry 
Text Enry 
Windows 
Colors 
Cursors 
: Response Time 
3.6.9. Help Messazes 
3.6.10. Exzor Messages 
3.6.11. System Foedback 





Figure 8. Lockheed Martin Human Computer Interface 
Requirements (HCIRS) contents (From: [6]). 








Per [6], the contents are meant to describe the 





interface between the user and the system. The “how” of 
software and hardware design is documented in separate 


specifications [6]. 


c. The Iterative Process 


Reference [6] has divided the design process in to 


eight distinct steps (Figure 9). 
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Step 1-Generate an Operational Concept 

Step 2.Define the Users 

Step 3.Elaborate Functions and Tasks 

Step 4.Analyze Human Tasks and Interfaces 

Step 5.Specify Computer Interface Requirements 

Step 6.Define a Human-Computer Interface Configuration 


Step 7.Specify Documentation 


Step 8.Specify Qualification Requirements 








Figure 9. Lockheed Martin eight step HCI design process 
(From: [6]). 


As stated earlier, this process is both sequential 





and iterative. Design teams will make decisions, review 
them with users and modify these designs an indeterminate 
number of times until a consensus is reached as to meeting 
the functionality of that particular system. “User 
evaluations of the prototype are conducted at various 


iterations to obtain users’ feedback early and incorporate 





it into the design, as appropriate” [6]. Iteration occurs 


between steps three and eight of the design process. 


Step three is the step in which “functional 
allocation” occurs. Here, “functions are allocated to 
humans or to machines” [6, p. 27]. Allocation decisions are 
based on several criteria including human and machine 





limitations and data from functional analysis, as well as 





past engineering experience and cost-effectiveness of 


design. To some extent, the remainder of the iterate 





process refine this mapping of functions to functionality 
and get it to work in the context of usability. This in 


turn makes step three the most crucial to the entire 


3 


iterative process. Any missteps here may prove 
irrecoverable for the remainder of the process. until 
iteration returns to the starting point. This logic can 


also be applied to the non-iterative part of this process 








starting at step one (Generate Operational Concept). If the 





concept is mal-formed, the entire process will thus be 


malformed since there is no way to recover without a 





complete re-initialization of th ntire design process. 








In summary, the reader should keep in mind that 
the ultimate goal of this design process is to map required 


system functionality (step 3 of Figure 9) to a specific 








functionality within the final design (step 8 of Figure 9). 





Once this criterion is met, it is possible to declare th 





system goals complete. This means that unless a very 


specific moving map requirement was specified (which was not 





the case in the original MH-60S ORD), the final design could 


vary widely and would most likely be the best solution from 





an engineering standpoint, not necessarily a usability 








standpoint. 
4. Digital Map Kneeboard (DMK) 
The introduction of Block and production models 


























and the implementation of the Armed Helo mission brought 


the need for a moving map to the forefront. Hamstrung by 





the FMC limitation as discussed in Chapter V, NAVAIR opted 





to integrate a kneeboard moving map and introduced a change 





to the MH-60S ORD that specifically outlined a kneeboard 





moving map specification [30]. Section 4.3.9 of [30] 


defines the requirement: 
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A kneeboard moving map which is useable during 
both unaided and Night Vision Device (NVD) flight 
will provide digital navigation for each pilot. 



































The aircraft will be modified to provide primary 
navigation (either INS or GPS) position 
information and power supply to support the 
moving map. The MH-60S kneeboard moving map 
shall be capable of pre-flight loading and in- 
flight display of National Geospatial- 
Intelligenc Agency (NGA) raster product format 
data and vector data that incorporates and 
overlays geo-referenced navigation and waypoint/ 














flight data onto a common map background. The 
moving map shall be capable of input and output 
in either latitude/longitude or Military Grid 
Reference System (MGRS) . When the Navy 


implements the Common Grid Reference System 
(CGRS), it will be incorporated into the moving 
map system. A cockpit moving map display greatly 
increases pilot situational awareness. A self- 
contained moving map system will be an objective 
system for the MH-60S. 














If a need for moving map was realized in the ORD, why 
was the kneeboard solution incorporated and not the “self- 
contained moving map solution” described above as the final 


solution? Before this question can be answered, a brief 





discussion of the DMK will be undertaken to orient the 


reader with the kneeboard solution. 


a. Digital Map System 





The answer to the Change 2 ORD requirement was the 











Digital Map System (DMS). Developed by Vertical-flight 


Systems, Test Analysis and Research (VSTAR), a government 























owned facility, the DMS consists of three distinct 
components (Figure 8 and Figure 9): a Digital Map Junction 
Unit (DMJU), a Digital Map Loading System (DMLS) and three 











Digital Map Keyboards (DMK) [7]. 
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Pilot Disconnect 
Cable 
















Crew Disconnect 
Cable 


Figure 10. DMS (From: [7]). 








Figure 11. Current fleet DMK. Pen included for size 
reference only. 


The current kneeboard moving map implementation 
was an offshoot of an older Fujitsu touchpad laptop that had 


been tested previously. Based on this concept the current 








kneeboard was designed and prototyped by NAVAIR during 2004. 


Production of operational models was handled by the Army 
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(AMRDEC) Aviation and Missile Research, Development and 








Engineering Center—Prototype Integration Facility (PIF) in 


Huntsville (Redstone Arsenal), Alabama [45]. 





Designed to be worn on the pilot’s thigh while 
seated in the aircraft, the kneeboard is approximately the 
size a medium-sized book or standard military kneeboard in 


length, width and thickness (Figure 11 and Figure 12) and 








weighs around four pounds [8]. User Human Machine Interface 





(HMI) controls consist of an 8.5-inch (diagonal) resistive 
touch screen, on/off switch, touch screen disable switch, 
backlight control and right mouse click switch. Software 
consists of Microsoft Windows XP© running the AN/AYQ -26 
Topographic Support Set (Figure 13). This set integrates 


aircraft navigation data with respect to digital maps [7], 














Forward Looking InfraRed (FLIR) composite video input, two 


10/100 Ethernet ports and a MIL-STD-1553B Data Collection 











PCB [8]. 





Figure 12. Current fleet DMK. Pen included for size 
reference only. 
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Windows XP Operating System 
VSImage Viewer S/W (Video Window) 
— FLIR video 
Map S/W 
— Faclonview/PFPS based 
Physical 
— Weight: <4 tbs 
— Size: Navy kneeboar 
Display 
— Sun-light 
- NVG Class B 
8.5” inch diagonal 
* White LED 
* Resistive Touch 
Human Machine Interface 


SO | 





* Brightness Ctrl 





Figure 13. DMK Specifications (After: [8]). 


Of particular interest is the integration of the 
mission planning software FalconView®© to the DMK . 


FalconView© is a common tool used by aircrew across all the 





services for mission planning. 





b. Pilots lLikes/Dislikes and Limitations of 
Heads-down Devices 


The in the scope of the interview conducted for 
this thesis, the DMK was universally discounted by all 
pilots interviewed as a useful front seat tool for any type 


of relevant geospatial situational awareness information. 





Based on comments documented in Appendix B, this is 


primarily due to the heads-down nature of the DMK. 








Interview subjects reiterated that the DMK was much more a 


distraction than help to mission accomplishment. 


This finding is not surprising. The negative 





impact of any heads-down activity in a cockpit is well 


documented and blamed for a number of aircraft mishaps [46] 





analyzed National Transportation and Safety Board accounts 
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of accidents attributed to crew error. Of those reported, 








“nearly half of these accidents involved lapses of attention 
associated with interruptions, distractions, or 
preoccupation with one task to the exclusion of another 
task.” Of these distracting activities, four categories 


were defined: 
e both internal and external communication 
e searching for VMC traffic 


e responding to abnormal situations 





e head-down work 


Reference [46] also analyzed 107 of NASA’s 


Aviation Safety Reporting System (ASRS) reports that 





involved competing tasks. Sixty-nin percent of these 











reports were attributed to “either failure to monitor the 


current status or position of the aircraft, or failure to 





monitor the actions of the pilot who was flying or taxing” 





[46]. In 35 of the ASRS reports, the pilot not flying was 
distracted from monitoring the flying pilot from other 


tasks, of which 13 involved some kinds of head-down 





activity. 


Airbus also conducted a review of safety reports 


and found similar data [16]. Based on the U.S. Aviation 





Safety Action Program (ASAP), Airbus stated that 
“interruptions and distractions are the main threat facing 


flight crews.” Airbus defines a threat as “a condition that 





affects or complicates the performance of a task or the 








compliance with applicable standards.” In reviews of the 
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ASRS, Airbus calculated that head-down activity accounted 





for 16-22 percent of the factors involved in interruptions 


and distractions, as listed in Table 5 [16]. 


Omission of action or inappropriate action 
Inadequate crew coordination, cross-check and back-up 


Insufficient or loss of lateral or vertical situational awareness 


Slow or delayed action 


Inadequate or insufficient understanding of prevailing conditions 


Incorrect or incomplete pilot / controller communications 


({ Sources : Flight Safety Foundation - ALAR - 1998-1999 ) 








Table 5. Interruption and distraction factors (From: [16]). 


The effect of these interruptions and 
distractions, in which head-down activity comprises almost a 
quarter, is to “break the flow of ongoing cockpit 


activities,” including [16]: 





e Standard Operating Procedures (SOPs) 
e Normal Checklists 

e Communications 

e Monitoring tasks 


e Problem solving activities 


The effects of head-down activity and the 
resultant laundry list of consequences above are no surprise 


to seasoned fleet aviators. Limiting head-down activity to 





a minimum is a golden rule taught in flight school and 


constantly reiterated during countless safety briefs and 
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squadron level training. The head-down environment is so 
distracting that announcing that the non-flying pilot is 
“heads-down” is very common practice and highlights the need 
for extra vigilance by the flying pilot as well as other 


flight crewmembers. Physiological affects aside, head-down 





is not an activity that should be performed often in the 


cockpit. 


This knowledge of the inherent dangers of head- 


down can also be interpreted from the U.S. Navy’s own 





research into glass cockpits. In researching moving-map 
systems for multi-functional helicopter missions, the Naval 
Research Laboratory did not even consider a kneeboard 
application and instead focused its research on an in-dash 


MFD integrated solution [47], [40]. 





Finally, [48] describes one of the potential 


hazards of advanced interfaces interfering with aircrew 





Situational awareness. It warns that “too much programming 
and head down times [that] takes place at low altitude, and 


during time of intense tactical activity,” is a concern when 





developing a new interface system (p. 8). 


c. Planned Obsolesce of the DMK 


Although sold as a solution to the moving map 





issue, NAVAIR did recognize that it was not the ideal 


solution. Per [7] and [30] this implementation of moving 





map functionality was inferior to a MFD integrated solution: 





“but the ultimate solution would be to integrate the moving 





map system into the normal OSI on the mission display [7], 





pe. LO] .” 
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Other than the fact of denying the users of the 


MH-60S access to a known superior navigation system in the 





hear and now, planning for a major systems change after the 
aircraft has started full-rate production is an expensive 
proposition and a well-known acquisitions “no-no” and 
harkens to the now-defunct serial-approach acquisitions 
process. Per [9] the most costly place to implement product 
changes are after operational testing or full-rate 


production as shown in Figure 14. 
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CONCEPTUALIZATION TEST AND SUPPORT 
AND DESIGN PRODUCTION 
TIME 
Figure 14. Cost of design changes as a function of time 
(From: [9]). 
B. DESIGN METHODOLOGY FLAWS AND A SUGGESTED ALTERNATE 


DESIGN METHODOLOGY 





Clearly, the DMK is a poor solution to the moving map 
issue. This statement can be made not only based on 


research presented above but also validated by nine of nine 
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pilots interview 








map despite th 


The question is 


d requesting the integration of a moving 


fact that one already exists in the DMK. 








still begged: how did the DMK become the 








solution? Per [49], the issue was timing. NAVAIR realized 





that the block 





Armed Helo navigation requirements could 











be solved by a moving map but was still limited by the FMC 





as previously discussed. The MC was planned as an upgrade 


but would not be 


The solution was 








ready in time for block incorporation. 








the DMK. But given all the issues with a 





head-down display, why was this solution not rejected as 








inadequate as interview results so clearly indicated? The 


answer could lay 





in the standard HCI design methodology 


utilized by Lockheed Martin. 


The primary 





incorporation of 


issue in the design process could be the 





previous designs in the generation of HCI 


requirements as described by [6]. This step calls for the 


“study of earli 


er Similar systems to identify firmly 








established interface practices and standards [6, p. 9]. 





The potential pi 


tfall here is the earlier system being 














reviewed. If that design is flawed, and that flaw was not 


recognized by the 


design team, the fundamental flaw has the 





potential to be carried over to the new design. Give the 


discussion of head-down issues from above, the conclusion 





that this is precisely what happened in the DMK can be 


reasonably drawn. 


Although in 
not a bad idea, 
still produced by 


to help eliminate 





itself the inclusion of a prior design is 
somehow a useless moving map solution was 


the design methodology. What can be done 





this chink in the design armor? A better 
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and ultimately more efficient approach to cockpit design may 


be a design philosophy commonly known as Crew-Centered 





Design (CCD). 





1. Crew Centered Design Philosophy 














The Crew Centered Design (CCD) concept is similar to 








the Lockheed Martin/DoDAF methodology in that it professes 





the same iterative approach to design in which 





implementations are prototyped and tested. It differs from 








the industry standard HCI systems ngineering approach in 








that it is less of a rigid methodology and more of a 





philosophy and emphasizes a more holistic view of cockpit 





systems integration with flight crew usability as a key 





component of that system. CCD places a much greater 
importance on input from experienced aircrew personnel “at 
the beginning of, and throughout, the cockpit design 


process” [50]. 


Although each instantiation of the industry standard 





iterative systems ngineering process centered HCI design 





methodology may be different from organization to 





organization, generally, they all follow the model detailed 


in Figure 15. This representation almost maps step for step 





to the Lockheed Martin process described in an earlier 


section of this thesis. 
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Previous Design, 
Production, and 
Operational Experience, 
Technology Constraint: 


External 
Requirements (Mission, 
Customer, Flight Crew, 

Environmental, 
Regulatory, Program) 


Flight Deck 
Initial Design 
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Aircraft Aircraft Aircraft Final 
: a Test and 
Operational Functional System - Integrated 
: 2 é Evaluation 
Requirements Requirements Requirements 


Initial Design 
Concepts 


Flight Deck 
Requirements 





Requirements 











Figure 15. Systems engineering iterative HCI design 
process (From [10]). 





While utilizing the general structure from Figure 14, 





the Crew Centered Design philosophy takes a completely 








different view of what is important in cockpit design. It 
de-emphasizes the performance of individual components and 
the sterile implementation of functionality and instead 
views success as how well the crew and cockpit perform 
together in the accomplishment of a given task. To this 


end, CCD places a much larger emphasis on the inclusion of 





the flight crew in every step of the design process [10]. 





Fundamental components of CCD include: 


e Acknowledgement that the flight crew has’ the 


ultimate responsibility for the aircraft [51]. 








e Inclusion of the user (aircrew) more intimately in 


the design process [10]. 
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e Consider the usability of the cockpit as 
system 


airframe integration 


such 


a mayor 
that it equivalent to engines and 
[10]. 
e Total flight crew/flight deck performance is more 


important that performance of individual components 


[10, 


e Test and evaluation 


p. 7] 


should occur as 


early in the 


design process as possible to avoid implementation 


of poor design decisions 


The 





Crew-Centered 


traditional 





Previous Design, 
Production, and 
Operational Experience, 
Technology Constraints 


Extemal 
Requirements (Mission, 
Customer, Flight Crew, 

Environmental, 
Regulatory, Program) 


Aircraft 
Operational 
Requirements 


Aircraft 
Functional 
Requirements 





Design 


Aircraft 
System 
Requirements 


PO les 


the 


philosophy 


applied to 


design methodology is depicted in Figure 16. 


Design 
\ Philosophy 


Flight Deck 
Initial Design 
Concepts 


Flight Deck 
Requirements 


Final 
Integrated 
Design 


Test and 
Evaluation 





SP philosophy may affect 
SP philosophy definitely affects 





Other Systems 
Initial Design 
Concepts 


Other Systems 
Requirements 


Notes: (1) Philosophy should affect design process wherever design decisions are explicitly or implicitly made 
For example, aircraft operational and functional requirements should be independent of design 
decisions, but often they are not; function allocations, pilot interfaces, and flight deck 
requirements are sometimes involved. 


(2) Philosophy should affect the operation or function of the aircraft if pilot roles dictate that the 
aircraft interact with the outside environment in certain ways (e.g., must be able to perform 
a visual approach or manual landing because the pilot has ultimate authority over critical flight 
functions). 








Figure 16. Inserting the Crew-Centered 


in to the traditi 








onal 


design methodology 





p. 
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Design philosophy 
(From: [10], 
21) 


As its name implies, one of the major elements, if not 
the major element, is frequent and focused input by the 
experienced aircrews that may operate in that cockpit 
environment. 

AY “OpLimiuzed. ~desten. dnd. analysis process: |-Crow= 

Centered Philosophy] should take advantage of 

aircrew input. The aircrew, aS a user, can 


provide a tactical evaluation of the design 
product and provide valuable insights. [50, p. 1] 





2. Recommended Changes to Lockheed Martin HCI Design 
Methodology Based on the CCD Philosophy 


There are several areas on which the application of the 








CCD philosophy would enhance the Lockheed Martin design 


process. These include: 


a. Use of Design Methodology Specifically 
Developed for Cockpit Design 





Design fundamentals and operating environments are 








not the same across the HCI spectrum. Fundamentally the LM 











method and its successor DoDAF are a broad approach to 





general HCI design. Given the highly dynamic environment of 





the flight deck, a set of very specific usability 





requirements exist. Reference [52] argues that “In the 
complex, dynamic, tightly regulated environment of aviation, 


the challenge of performing a usability evaluation expands 





considerably in comparison to evaluation of traditional 





human-computer interaction (HCI) applications” [52, p. 396]. 





Unlike other stationary systems that are captured by general 





HCI design methodologies aircrew face a much more dynamic 
and thus fundamentally different design context. Regardless 


of the current task for the aircrew “The most important task 
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is aviating—-keeping the flow of air over the wings such as 
to maintain lift [53, p. 460] That is exemplified in the 
flight school mantra of aviate, navigate, communicate! 
Regardless of secondary tasks these three tasks must still 
be accomplished with absolute precision since the price of 
failure usually catastrophic. There is therefore a constant 


competition in the flight deck environment for the resource 





of pilot attention. 


The competing tasks involve maintaining situation 
awareness for hazards in the surrounding 
airspace, navigating to 3-D points in the sky, 
following procedures related to aircraft and 
airspace operations, communicating with air 
traffic control and other personnel on the flight 
deck, and monitoring system status. [53, p. 460] 





This specific task environment cannot be said of a 
user of a desktop terminal or even an operator of a 


sophisticated nuclear power plant control station for which 





a general HCI methodology would cover. Reference [6] does 





attempt to make this point. In step one, it directs systems 
engineers to capture “operational modes; and any special 


environmental conditions that must be accommodated by the 





system [6, p. 27]. Depending on the expediency of the 





project, this broad brush approach to capturing the 
operating environment has a lot of potential to miss crucial 


elements. Plus, understanding that the fundamentals 





described above are common to any cockpit design, it seems a 
waste of resources to continually re-invent the wheel for 


each functional requirement. 
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b. Cost Effectiveness Must be Evaluated from a 
Holistic Standpoint 


Limiting cost as a design criteria: Per the 





Lockheed Martin method “the most cost-effectiv design 


alternative is selected [6, p. 26, Figure 6] during step 3 





of the iterative design process. Although cost is an 


important element, it should not be applied as the bottom- 





line selection criteria for each individual function. CCD’s 





philosophy of viewing the system as more than the sum of its 
parts must also be applied to the cost criteria. A 


functional requirement that costs more may in fact drive 








down the cost of a related function. Thus, cost comparison 
may b better served by evaluating th ffectiveness of 
aircrew tasks (or combinations of functions). For example, 


if “navigation” was evaluated as a task, several functional 








requirements may be included in this grouping. Since CCD is 
crew-centered and more dependent on “operator input and 
experience” [50, p. 1], there is a greater chance that 
aircrew will recognize that task accomplishment would be the 


criteria for success instead of simply meeting a functional 





requirement. In short: meeting a functional requirement 











does not mean that the task is accomplished in the most 


efficient way. 


c. View the Cockpit as a Sum of Its Parts for 
Design Decisions 


Eliminate a function by function approach to 
design: The current accepted cockpit design methodology 
used on the Common Cockpit evaluates each functional 


requirement as a pseudo standalon requirement. CCD’ s 








holistic aircrew centered approach would tie common 


53 


functional requirements together and address that the whole 








may in fact be greater than the sum of the parts. It is 


easy to conclude that understanding the underlying need for 





geospatial situational awareness an experienced flight crew 





would immediately be able to connect the dots between 





different requirements for mapping. 








In the case of the Common Cockpit, the need for 


geospatial positioning is scattered throughout each 





different aircraft block requirement in the MH-60S ORD. For 
this discussion the reader should note that this Common 
Cockpit requirements review has been limited to just the MH- 
60S ORD and does not factor in functional requirements 


defined in the MH-60R ORD. 








Block I aircraft, section 4.1.2 of [30], as well 











as section 4.2.4.1 of Block requirements, requires that 











the “MH-60S Communications and Navigation subsystems are 
required that will enable aircraft to operate within the 


Global Air Traffic Management (GATM) system [30, p. 14].” 

















The GATM: 
Is a concept for satellite-based communication, 
navigation, surveillance and air traffic 
management. The Federal Aviation Administration 
and the International Civil Aviation 








Organization, a special agency of the United 
Nations, established GATM standards in order to 

















keep air travel safe and effective in 
increasingly crowded worldwide air space. [54] 
Block navigation requirements are outlined in 
section 4.2.1.1 of [30]. The AMCM specific requirements 











state that the “cockpit displays shall provide the 





capability for the aircrew to maneuver the helicopter along 











a desired/selected track (p. 19).” Unlike Block I and 
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communication and navigation requirements, oddly Block 





navigation and situational awareness requirements completely 








forgo any mention of GATM and instead section 4.3.9 





describes the functionality requirements of the DMK 
discussed in detail above [30]. Communications and 
navigation requirements are also outlined in the Other 
System Characteristics subsection (4.6) in sections 4.6.6 
and 4.6.7, respectively. Neither section mentions GATM but 
4.6.7 outlines a functionality that could be construed as a 


Situational awareness tool for GATM implementation: 





The MH-60S helicopter shall have the capability 
to pre-load (both electronically and manually) 
geo-referenced navigation waypoints and flight 
plans, and provide the ability to manipulate 
these waypoints/flight plans in flight. The 
navigation system shall be capable of displaying 
to the pilots the position of surface contacts in 
and around the battle group. [30, sect. 4.6.7, p. 
3:5. 























A possible side effect of sprinkling functional 








requirements throughout, may be that the same functional 





requirement would be designed two different ways in two 


different projects. In the case of GATM, the Common Cockpit 





had no specific resultant usability other than a basic 
avionics package and rudimentary mapping abilities discussed 


below. This would then seem to meet the functional 





requirements specified by the MH-60S ORD sections discussed 
above. However, when Lockheed Martin designed the glass 


cockpit for the improved avionics suite for the Air Force C- 





5, the result was a true moving map based on Commercial-off- 


the-Shelf (COTS) packages found in the Boeing 777 among 


oy) 


others [55]. Of course without an in-depth analysis of the 





C-5 program, it is impossible to make this correlation with 





100 percent accuracy. 


Finding cockpit functional requirements should not 











be like hunting for Easter Eggs. By eliminating the stoic 








focus on stove-piped design, CCD ties these initially 





disparate functional requirements together by recognizing 





that they all accomplish the same basic task of geospatial 








positioning. The end design result would be a much better 


integrated mapping system that may potentially greatly 





reduce costs and improve system flexibility in the long run. 





The need to unify cockpit requirements in to one 





encompassing ORD is also a desire of the program manager per 


echo ae 


d. Carefully Consider Incorporating Previous 
Designs 


References [56] and [11] indicate that one of base 


designs for the CC was the Light Airborne Multipurpose 





























System (LAMPS) MK Block program. This is due to the 





fact that the MH-60R is a replacement for the current LAMPS 























SH-60B as stated earlier [4]. The LAMPS MK system was 
introduced in 1983 and modified in 1992 [57]. Reference 
[l1, sect. 6.2.2.1.1] states that mission display geo- 


situational symbology was “designed to be compatible with 





the specifications for Naval Tactical Display Symbols (NTDS) 








to insure compatibility across Navy platforms.” In keeping 





with good design practices, “an evolutionary—as opposed to 


revolutionary” [51l]-was employed and much of the previous 
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display symbology was preserved. Having its roots in the 
1980s display technology, NTDS is a bare-bones graphical 
display in which: 








Aol eh: on-screen shape coding (including the 
contact and track shapes) is suggestive, in some 
way, of the object or parameter being represented 
in order to facilitate operator recognition. The 
top half of a geometric shape represents an air 
contact, an ntir geometric shape represents a 
surface contact, and the lower half of a shape 
represents a subsurface contact. ; The SAR 
Reference Point is the same shape as the "man 
overboard" Naval signal flag; the Pointer symbol 
consists of an arrow; the Torpedo Splash Point 
looks like a torpedo entering the water, and so 
on. [11, sect. 6.2.2.1.1] 

















Did this requirement to incorporate an existing 


design per step three of [6] unduly influence the final 








navigation display? Considering that the traditional 


navigation display of older U.S. Navy rotary-wing aircraft 








consists of green symbology on a black background (TACNAV of 
UH-3 first introduced in the 1960s, for example), one can 
compare that against the final CC design of Figure 17 and 
conclude that it did. 
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Figure 17. The current navigation display of the CC 
(From: [11, Keys cockpit interface simulator]). 


PLAN 











It should be noted that the MH-60S ORD does not 








specifically state the need for a NTDS type display for 


navigation but does require the same general functionality 








per [30, sect. 4.6.7]. It should also be noted that 





utilizing the NIDS symbology in itself is not a bad idea as 





it leverages xXisting user knowledge. However, sticking 








with the exact display environment despite clear potential 


for improvement could be considered a mistake. 


As such, it can be argued that the previous 
examples reviewed for the Common Cockpit are so far removed 


from an all-glass cockpit that their inclusion as a basis 








for design was more of a hindrance than help. 
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VI. CONCLUSIONS, RECOMMENDATIONS, AND FURTHER STUDY 


A. CONCLUSION 


On paper, Lockheed Martin met every functional 





requirement specified in the ORD in relation to the Common 


Cockpit. All applicable acquisitions instructions and 





design methodologies as required in the Department of 





Defense Directive 5000.1 were followed. The cockpit was 





tested, evaluated and approved by the Program Manager and 
delivered to the user. However, based on the results of the 


interview summarized in Appendix A and discussed throughout 





this thesis, the final design produced overlooked a critical 





display required to effectively and safely perform 








navigation tasks. In an attempt to fill this’ void, 
acquisition managers implemented a strap-on (kneeboard 


mounted) moving map system without adequate consideration to 





the usability of such a system. The result of this piecemeal 





approach to a moving map solution is the MH-60 cockpit in 


which the user is left wanting. How did this happen? 





Perhaps the process itself is to blame. 


B. APPLYING CREW CENTERED DESIGN 


As argued above, the Lockheed Martin design 








methodology, which is now standardized in the DoDAF 








methodology [58], is inadequate for glass cockpit design. 





It is too broad-based and does not adequately capture the 





essence of modern cockpit design. This failure manifested 


itself in the complete lack of a fully integrated moving 








map, despit th functional requirements (even with the 
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exclusion of the DMK requirements) and well-documented 


benefits to the aircrew for enhanced situational awareness. 





A better approach would be to detail glass cockpit 





specifics. This recommendation is discussed in the 


“Recommendations” section of this thesis. 








If the CCD process was applied to the Common Cockpit 


requirements, what would the result be? Without a full 








implementation of CCD, it is impossible to say. However, a 





brief exploration of the CCD philosophy with regards to MH- 








60S ORD defined functional requirements can be had with the 


following assumptions: 


e Step one of the CCD process (previous design, 








production, and operational xperience, technology 
constraints) will only be considered. The end goal 


of this evaluation is simply to fulfill the 





requirement of step one of [6, p. 9] to “generate an 


operational concept”. 


e The latest version of the MH-60S ORD will be 





considered [30]. 


e Current technology limitations of the Common Cockpit 





will be considered but will not be a limiting 


factor. The assumption is that if a technology 





requirement Xists, it is technology feasible to 
implement in the current common cockpit within 


reason. 





e The normal manning requirements for a HCI design 





team for step one is made up solely by the author. 
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1. Functional Requirements Evaluated 


As discussed above, Common Cockpit functional 


requirements are scattered throughout the MH-60S_ ORD. 





Grouping them together yields the following composite 


requirement: GATM capable (4.1.2); Maneuver the helicopter 








along a desired/selected track (4.2.1.1); kneeboard moving 


map which is usable during both unaided and Night Vision 








Device (NVD) flight (4.3.9); capability to preload geo- 








navigation waypoints and display, display the pilots 





position relative to surface contacts via Global Positioning 


System (GPS) (4.6.7). All requirements are from [30]. 








Even without the inclusion of the direct requirement to 


implement a kneeboard moving map in (4.3.9), in the author’s 





opinion, the sum of the requirements, as well as practical 
experience with in-flight navigations in the form of paper 


charts, would lead xperienced flight crews providing 








operational experience in step one to the conclusion that 


the fundamental task being accomplished by these outlined 





functional requirements is that of geo-positional 


Situational awareness for the flight crew. 





Finally, there are a host of considerations in choosing 
a moving map including perspective, orientation and size. 


But above all this there is the primary consideration: 





A primary Naval Air Systems Command (NAVAIR) goal 
in specifying the new system is to- enhance 
Situational awareness (SA) and aircrew mission 

ffectiveness without further burdening pilot 
task workload. [59, p. 1] 











It is by this guiding requirement that the operational 





concept shall be defined. 
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2. Mapping Options 


Now that the functional requirements have led the 
generation of an operational concept that includes a moving 
map, the team must determine what kind of moving map should 
be included. This is a job for the knowledgeable Human 


Factors engineers on the team. 


One key to determining map orientation may be the 





context for which navigational directions ar presented. 





Per [13, p. 110], “the language of the displays, in terms of 





go-referenced directions like left, right, above or below, 





should match the language of the control that is also 





typically represented in such ego-referenced terms.” The 


team should assume that if navigational directions are given 








to the pilot in terms of ego-centric commands like “turn 


left in 10 seconds,” then the map orientation should be 








direction up. If commands are in the form of “turn north to 
a heading of 350 degrees,” then north up iS a more 
appropriate directional context for the moving map. The 
previous reference is known as go-referenced or local 











guidance while the later is world referenced or global 





awareness [13, pp. 110, 113]. 





In [13] the two distinct views of Ego-Referenced 
Framework (ERF) or World-Referenced Framework (WRF) are 
described. Ego-Referenced Frame (ERF) provides the “user 


centered” view in which the view is presented as if seen 





from the user’s eyes. World-Referenced Framework (WRF) is 





less ecological in nature. It presents a view in which the 


observer is able to orientate himself in the world of 





reference. It is a view in which the ERF is just one part 








of the larger world. Sinc Crew-Center Design places 
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emphasis on task accomplishment (in this case navigation), 
both perspectives will be viewed by the specific tasks they 


accomplish. 


It should be clarified that for the bulk of their 





discussion, [13] discusses WRF as a function of both a 








three-dimensional (3D) and two-dimensional (2D) display. 





For the purpose of this thesis, a  three-dimension 





representation for WRF is ruled out for one primary reason: 


there are not currently enough navigational data points to 








present any WRF operating environment in 3D. It should be 








noted that there is no reason to believe that a 3D 





environment suitable to WRF mapping as described in [13] 
could not be constructed in the near future. Both airspace 


management, as well as operational environments, could be 








modeled in 3D, much as they are for simulators. It is 
realistic to anticipate that near future operating 


environments will be mapped in 3D, much as Google Earth has 











done by converting 2D imagery into 3D maps. Therefore, 3D 


should be a consideration for future upgrade plans. 


a. Ego-referenced Frame 





In [13, pp. 110-111] ERF is described as “ego- 








referenced, forward viewing, zoom in, and 3D.” ERF 
“mimic[s] the natural viewing of human observers as they 
walk through an environment [13, p. 111].” Ego-referenced 


refers to one of the four cardinal eye points a viewer can 





have: egocentric, exocentric perspective, exocentric 2D plan 








view (Figure 17), and exocentric 2D side view (Figure 18). 








For the purposes of this discussion, ego-referenced and ego- 
centric are the same viewpoints as depicted in Figures 18 


and 19. 
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Figure 18. Egocentric, Exocentric perspective, and 
Exocentric Plan-view displays (From: [12]) 





Exocentric 2D side view 


World Referenced 


Global Awareness 








Figure 19. A progression of viewpoints from ERF to 2D 
planar view. Exocentric 2D side view is on the far 
right (After: [13]) 
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b. World-referenced Frame 











It can be stated that a 2D plan-view is nothing 








more than a specialized case of a 3D WRF in which there is 





no off-vertical-axis view. Per [12], the 2D plan-view is 











described as akin to the 3D WRF from Figure 18, but “where 








the viewpoint is 90 degrees to the world’s plane.” Despite 








the conversion from the 3D WRF to the specialized case of 


2D, the three fundamental features of WRF described by [13, 








p. 111] are still valid: 





(a) they may need to be world-referenced to 
support communications with others who may not 
share the same momentary ego-frame of reference; 
(b) they should soon out or be wide angle, 
representing a much broader region of the world 
than does a local guidance display; and (c) the 
need for three dimensionality that was inherent 
in local guidance displays is mitigated by the 
desirability of a world-referenced frame; this is 
because a 3D display must by definition assume a 
particular ego-referenced azimuth angle. 























3. 2D/3D Solution 


Although it presents some very unique benefits to 





geospatial situational awareness, as discussed by [13] and 





[12], 3D also carries with it some significant baggage in 





today’s cockpit. Three-dimensional representations would be 








a Significant perceptive leap from the 2D paper charts and 
video displays in use today by flight crews. This may 


violate the “evolutionary, as opposed to revolutionary [51]” 








construct discussed previously. This point is made by [13, 


Pp» L113): 
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Although counterarguments [for 2D plan-view maps] 
have been made in aviation that a moving aircraft 
or stabilized world display is more compatible 
with the pilot’s mental model of the aircraft 
system (Johnson & Roscoe, 1972) and can provide 
as good performance. 














It may also be limited by the technical limitations of 











current or near future display technology. To declare 3D as 


the primary source of navigation information for today’s 





Common Cockpit would therefore be a stretch at best. To 








fully recognize the benefits of 3D, a Heads Up Display (HUD) 





and augmented reality, as discussed by [12], would have to 
be considered. This extensive modification to the Common 
Cockpit is well beyond the scope of this thesis. As a 


secondary source of geospatial reference, a simplified 





version of a 3D ERF display is a possibly, as will be 


discussed below. 


a. 2D Moving Map 





As discussed above, the benefits of a 2D plan-view 





moving map are undeniable. The question then arises as to 





what features this moving map would incorporate? 


Through an interview of both fixed-wing and 





rotary-wing pilots utilizing several types of 2D WRF plan- 


view maps [59] concluded the following: 


e Context switching (time to switch between 
different map views): “Faster is better 
accurately sums up the pilots’ preferences with 
regard to all three time-to-switch functions 
(switching map modes, switching chart scales, 


and command lat[itude]/lon[gitude] repositions 
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(p. 14).% No more than 1 second between context 














Switches was generally acceptable (Section 
4 Ue 3) 

Data update rates: In this case, faster is not 
better. Pilots preferred 15Hz [updates per 





second] displays over 20Hz displays (p. 14, 





Section 4.1.3). 


Map Positioning: North-up, track-up, centered, 





and decentered wer considered. Most pilots 





found that more often than not that track-up 
generally proved more useful than north-up but 


both had their advantages depending on the 








situation. As discussed in [59, pp. 18, 19], 
pilots accomplished “certain tasks (e.9g., 
reconnaissance) mor ffectively with a north- 





up map (p 19).”% In both north-up and track-up, 
pilots preferred the ability to determine 


whether the aircraft was centered or de- 





centered and to what degree off center the 


aircraft would be (Section 4.2.3). 


Zooming: The ability to both zoom-in and zoom- 
out on a map were shown to be beneficial. Of 


particular interest is the quick zoom-out 





capability in which a pilot can quickly attain 











a larger global situational awareness picture 


and then zoom-in to the original scale with a 








single button push (Section 4.3.2). 





Vector Moving Map Displays: Vector maps can 


have the same appearance and content of any 
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traditional chart but instead of being a 
digitally scanned picture of the chart are 
instead digitally rendered such that scaling 
and rotation have no effect on readability. 


“Vector maps are rendered from individually 





stored objects (p. 44). These objects include 


anything that would be found on a traditional 








map “including lines (i.e. roads), points with 
associated symbols (A Ken) airports), text 
features (e.g., city names), and areas (i.e., 
shaded metropolitan areas) (p. 44).” Vector 


maps can also be modified on the fly by adding 


symbology and objects not originally found on 





the map. It was concluded by [59] that the 


advantages vector maps had over digitally 











scanned maps were numerous. Of note “virtually 








all helicopter pilots gave all three 





capabilities (keeping text upright, selectively 
de-cluttering, and adding detail) the highest 
possible rating (extremely useful) [ps 45, 
sect. 4.6.2]. 





Map sources should include all navigational charts 











(including Digital Aeronautical Flight Information File 











(DAFIF) data) and tactical charts currently available to 





aircrew. In addition, satellite imagery should be included 
to capture areas not covered by existing charts. A hybrid 
between both types of maps would be ideal in order to 





provide the pilot with the maximum amount of geographical 
data available. The hybrid feature found on many on-line 


mapping tools such as MapQuest © and Google Earth © provide 
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xcellent xamples of this concept. These functional 


requirements are outlined in section 4.3.9 of [30]: 


Moving-map shall be capable of pre-flight loading 
and in-flight display of National Geospatial- 























Intelligenc Agency (NGA) raster product format 
data and vector data that incorporates and 
overlays geo-referenced navigation and 
waypoint/flight data onto a common map 
background. 





The MFD moving map design described above has many 





traits in common with the current DMK implementation. This 





follows as much of the functional requirements of a MFD 








integrated moving map are found in the DMK. Thus; en 
keeping with the philosophy of leveraging existing 


“engineering experiences [6, p. 26]” when developing new 





designs, the DMK interface will be used as a basis. The 


reader should keep in mind that interview complaints about 





the DMK had more to do with the kneeboard implementation 





than the actual interface. That said, a one-for-one copy of 











the DMK interface is not the solution. A more specific 





interview on the likes and dislikes of the DMK interface 


should be conducted to eliminate the wheat from the chaff 





and identify any interface issues. 








Inclusion of the DMK interface in the design 


concept also brings in to play FalconView©. Just like the 





reuse of DMK in order to leverage existing aircrew training, 








this system will be based on FalconView© and Portable Flight 





Planning Software (PFPS) commonly in use throughout military 


aviation. FalconView®O: 





Is a non-proprietary GOTS (Government Off-The- 
Shelf) application for analyzing and displaying 
geographical data crucial to the warfighter. Its 
ease of use and wide variety of applications have 
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made it the system of choice for the warfighter 





and the standard for data interchange in Iraq and 
Afghanistan. [60, p. 1] 
The primary benefit of FalconView© is it “supports 











a robust set of programmer interfaces, which allow diverse 
applications to fuse their information into a single 
coherent picture of the user’s area of interest [60, p. 2].” 





Areas of interest could include a benign flight across the 


United States or a more hostile flight in to enemy 





territory. Hither way it is captured. The ability to port 








this data directly to a moving map display is extremely 





useful and is without doubt the primary motivation behind 


DMK. 





its usage on the Using FalconView © is also in keeping 


with the spirit of incorporating “evolutionary—as opposed to 
[51] 


revolutionary changes in the cockpit. 





into 





One major issue with in 


the MFD moving map solution is 





planning. Since the DMK is a 


Windows 


mapping of FalconViewO© usability 





the to the DMK 





squadron in the 


environment and user interfac 


XP© operating environment, 


tegrating FalconView®O 





the question of in-flight 


fully functioning native 


there is a one-to-one 


from the PFPS laptops in 


aircraft. The operating 








are significantly different 





functionality of in-flight user 











functionali 


ty was not specifically 


devices in the common cockpit 


and present a challenge to the 


updates. Although this 


identified in the MH-60S 





ORI 





D, 








it is an issue that must be addressed. 


The primary 





issue is therefore whether a technical limitation exists in 
the cockpit environment that would prevent all of the 
FalconView© flight planning functionality from being 
available. This would warrant a closer examination and is 


beyond the scope of this thesis. 
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To that end the assumption 


will be made that at least limited flight planning 
functionality is available in the MFD moving map design as 


detailed in the existing functional requirements from 








section 4.6.7 in which the system shall “provide the ability 





to manipulate these waypoints/flight plans in flight.” 





b. 3D ERF FLIR 


A more radical design departure from the current 








common cockpit convention would be the integration of a 








pseudo 3D ERF display to assist the non-flying pilot with 


Geo-positional situational awareness. This design would be 








pseudo in the fact that true 3D would is technically limited 








in the current common cockpit. The goal is to attempt to 





capture a mor go-referenced display since “(ego 


referenced) maps support better navigation performance, as 





these tend to both to alleviate mental rotation and provide 





a left-right display frame of reference that is compatible 


aw 








and congruent with the frame of reference of the control 





Ei Sy op. “LISI. 





A true 3D ego-centric ERF display would most 








likely involve the projection of a 3D environment on some 
type of heads-up display, as described in PAu 2 


Acknowledging realistic technical limitations, the goal of 








this ERF implementation would be to assist the non-flying 





pilot with navigational reference under the assumption that 


he or she would be “backing up” the flying pilot as is often 





the case in high workload cockpit environments. 
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The operating environment for this implementation 


would be in a tactical situation in which local guidance is 





the preferred means of navigation as outlined in [59]. Such 











missions include NVD Nap-of-the-Earth (NOE) flights, as well 


as overwater surveillance missions. 





The design would superimpose current HUD symbology 


found on the NVD kit to the MFD FLIR image. The FLIR image 

















data would provide th go-centric view found associated 








with a 3D ERF while the HUD projection would help the non- 





flying pilot referenc th current condition of the 





aircraft. This display would thus provide both geo- 





positional data as well as aircraft status in one glance. 
The reason this data would be designed for the non-flying 


pilot is that the majority of the viewing is done while 





scanning inside the aircraft (MFD scan) and not outside as 


is the case for tactical environments. 


The inclusion of this functionality has the added 


benefit of including both the ERF and WRF perspectives. As 





discussed in [12] and [13], this is the ideal solution. 





4. Symbology and Color Scheme 














The Department of Defens Interface Standard—-Aircraft 














Display Symbology (MIL-STD-1787C) is the standard for 

















display symbology throughout the Department of Defense. It: 











Defines the symbology requirements for a primary 
flight reference and describes some fundamental 
relationships between symbol motion and aircraft 
system states. It describes symbols, symbol 
formats, and information content for electro- 
optical displays that provide aircrew members 
with information for takeoff, navigation, terrain 
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following/terrain avoidance, weapon delivery, and 








landing. It also provides (in appendixes) non- 
binding information on symbolgy, geometry, fonts, 
recommended dimensions, and mechanizations. [6l, 
p. 1] 


Given the depth and breadth of this document, the 





design team will use it as the standard for display 
symbology. 
C. RECOMMENDATIONS 


The intended scope of this thesis is an examination of 
the Common Cockpit associated with the MH-60S and MH-60R and 
recommendations on the improvement of that program will be 


made. Some of thes recommendations, however, are more 





broad-based and applicable to th ntir defens 





acquisitions process outlined in [62], as it relates to 





glass-cockpit design. Recommendations are thus divided into 





these two categories. 


1. Common Cockpit Recommendations 


The author is keenly aware that in reality the chance 


of a complete redesign of the Common Cockpit due to cost 














alone is slim. In relation to “trade-offs” with the current 





common cockpit, cost would seem the only issue as the basic 
technological requirements are already in place. Realistic 


recommendations are thus: 


Implement a moving map: Nine of nine pilots interviewed 








said an integrated MFD moving map would greatly improve geo- 





Spatial situational awareness during every aspect of flight 











regardless of mission. NAVAIR as well recognized this fact 








and developed the practically useless DMK as noted earlier. 
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Considering the positive impact a truly MFD integrated 





moving map would have, NAVAIR should expedite this design 


well ahead of the current plan to field it in 2016, assuming 








it gets funded [35]. It should be noted that Lockheed 








Martin, as a result of the IRAD discussed above, has already 





developed a prototype moving map that integrates graphical 


map overlays (navigational maps, etc.) with the existing 





NTDS style symbology found in the current Common Cockpit. 


Reprogram the Common Cockpit: Elevate the Common 
Cockpit program to an Acquisitions Category (ACAT) instead 


of its current 845 status. This will help nsur 











requirements are clearly stated and allow better management 


of costs and funding. 


2. Defense Acquisitions Recommendations 


Implement Crew Centered Design in the DoD acquisitions 





process: In today’s modern computer centric aircraft, 


reliability of the aircraft as a system is rapidly being 





overshadowed by usability as the number one design issue. 


Appendix eight of [62] clearly recognizes this shift and 





states the Program Manager of a DoD acquisitions program: 











Shall have a plan for [Human Systems Integration 
(HSI)] in place early in the acquisition process 
to optimize total system performance, minimize 
total ownership costs, and ensure that the system 
is built to accommodate the characteristics of 
the user population that will operate, maintain, 
and support the system. [p. 60] 











Enclosure eight continues by discussing a broad range 


of issued including training and survivability. Although 








necessary at a high level, this broad-brush approach to HSI 








is insufficient when dealing with cockpit design, as 
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evidenced by the Common Cockpit. Given the complexity of 
the modern cockpit, associated pilot workload and the 
uniqueness of the cockpit operating environment, a very 
specific methodology must be outlined to address its design 


and implementation. To this end [62] should specifically 








nam Crew Centered Design as the sole method of manned 





cockpit design. 


Refine ORDs to be as specific as possible to reflect 





user needs: Ensure that Operation Requirements Documents 

















(ORD) or Initial Capabilities Documents (ICD) as described 


in [62] are written as clear and concise as possible. 





Functional requirements should be justified via sound 
scientific methods and well understood by the Program 
Manager. Acquisitions professionals should understand that 
the contractor is bound by the contract to provide what is 


asked for, not necessarily what is needed. 


Combine efforts across DoD to produce a truly Common 
Cockpit: Expand the notion of cross platform cockpit 
commonality by following the example of the U.S. Army’s 
Common Avionics Architecture System (CAAS), in which the 


same basic cockpit architecture is used in the Army’s 





xtensiv fleet of dissimilar rotary-wing aircraft. By 





combining resources and leveraging the existing development 








xperience, the Navy can make the next generation of Common 


Cockpit truly common by employing it across all new 





Navy/Marine Corps rotary-wing aircraft. This is not to say 





there will not be differences between cockpits, but it is an 
acknowledgement that the fundamentals of aviate, navigate, 


communicate are common functional requirements of any 





cockpit. 
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Examine the integration of Human System Integration 
across all acquisitions projects that have human-machine 
interactions: Although this thesis is specific to the 
Common Cockpit, this issue is just one example of the much 


broader issue of usability across all human-machine 





interaction. HSI applies as much to cockpits as it does to 


any type of device that requires direct human interaction. 








In fact, the fundamental usability of a cockpit is not that 











much different than that of a door handle: the design must 





be usable or it will not get used. Through the use of 











methodologies such as CCD briefly described in this thesis, 


the acquisitions process must seek proven and effective ways 














to integrate HSI with existing industry design practices and 





standards for the HSI requirements of [62] to become truly 


effective. 
D. FUTURE WORK 
During the interview conducted in San Diego, 








respondents identified two potential areas of research in to 


Common Cockpit shortcoming. These include: 


e Two interview subjects recommended the integration 


of a Flight Management System for improved airway 








navigation. An example of this is Sikorsky’s glass 





cockpit solution and with an integrated FMS 800 
[63]. 


e Five of nine interview subjects indicated 





dissatisfaction with the several aspects of the 








Forward Looking Infrared (FLIR) implementation to 





include image display size and the usefulness of the 
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Hand Control Unit (HCU). Further exploration in 





this direction is warranted. 





Four of nine pilots interviewed expressed some level 











of dissatisfaction with the current PKI / FFK layout 
and menu depth associated with these keys. Further 


exploration in to the usability of the current setup 





against the guidelines established in NAWCADPAX 








“Situational Awareness Guidelines.” 





Explore the possibility of an ego-centric 3D 





augmented reality HUD for the Common Cockpit. 
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APPENDIX A: INTERVIEW RESULTS SUMMARY 





Nine subjects were interviewed over a three-day period. 


Although scheduled to last one half of an hour, the 





interviews lasted on average an hour. A summary of 


questions asked in Appendix A are provided below. 


A. SUMMARY STATISTICS 


e Total hours (median): 1300 


e Total MH-60S hours (median): 1000 








e Total previous qualified Helicopter in a different 


series: 2 


B. QUESTION SUMMARIES 





The following represents a summary of the questions 





asked during the interview process. Although some themes 
were common throughout the interviews, some subjects brought 
out unique ideas and observations. 


1. What MH-60S missions are you most familiar with? 
(SAR, LOG, MEDEVAC, etc.): 


All the subjects were familiar with the basic FRS 
missions, including Search and Rescue (SAR), Logistics 


(LOG),and basic flight familiarity training (FAM). All were 





also familiar with Armed Helo mission (TACTICS), although 








th xperience level varied from entry level to advanced. 
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Given your experience in the above missions you 
highlighted, tell me about instances for which you 
may have experienced difficulties with the cockpit 
interface while conducting those missions: 


A wide variety of issues where presented. Concepts are 





grouped below: 











Multifunction Display (MFD) readability: Initial 





boot contrast defaults to the lowest setting thus 





requiring the user to adjust contrast to a higher 





setting to be readable. Also, several magenta 
colored displays (needles and heading settings) were 
not readable, particularly on the edges of the 


viewing area. 











Forward Looking Infrared (FLIR) Hand Control Unit 
(HCU) : 


What are your general likes and dislikes with the 


cockpit interface? 
Likes 


The joystick interface pointing device was mentioned 
as effective. However, the variable rate in which 


scroll rate is somewhat proportional to joystick 








displacement took practice to master. 





Dislikes 


Layered menus were almost universally mentioned as 





an issue. Specifically mentioned was the thr step 








process of switching the IFF transponder from 


“Transmit” to “Standby.” 
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3.3 Are there any other MH-60S interface issues that 


you would like to describe or may be relevant 
this study? 





This question almost completely revolved around 


elimination of the current kneeboard implementation of 


to 


the 
the 





moving map functionality and replacing it with an integrated 

















moving map display in the Mission Display (MD). 


4. Finally, if there was something you could change 


about the cockpit, what would it be? 


By the end of the interview process, this question was 


both asked and answered as a result of discussions from 


questions c and d above. However, a few subjects mentioned 


other items not previously discussed during their interview, 





including the need for more comfortable pilot seats, better 





visibility from the cockpit, and unified helmet cord that 








integrates Internal Communications Systems (ICS) and all 











Night Vision Device (NVD) functionality. Also mentioned was 


changing the airspeed indication tape to a more readable 


format and a way for aircrewmen to monitor aircraft altitude 


in low-level situations. 
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APPENDIX B: RAW INTERVIEW DATA 


TABLE OF CONTENTS 
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Once the interview is complete, the interviewer will 
thank the participant for his or her time and ask if there 


are any follow-on questions. 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: 2S. 
2. Total hours (MH-60S): /00 


3. Previous model qualified HAC?: ho , (ut AAC 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 


(SAR, LOG, MEDEVAC, etc) 


RP- SAR NSW , Fi 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 


= “TACT Pe rela wih — fries (EX: Peal fo teraces 
+o Crag, Check _ beep e Hon sale 


~ Nav 
Pauigation ~ be ae / 69S fhght gion [phe v 


3. What are your general likes and dislikes with the 


cockpit interface? 


Likes: 


“fist modes (AP ek 
3 
~ [rool iy ot asi [Ae [atio 
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Dislikes: 


= flo pntegeted Po GBR dae Ging Av fob 


4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 


he we (Qn dlket  disphyc 
~ Je ahet fy er clog lay Le See oe eT 


"go Ore seflirg Di 
— More Cudble fore dor Fire / Eyire. oot 


5. Finally, if there was something you could change 


about the cockpit, what would it be? 


Betlr vised ty theayh — the Floor 
~ Che Carel ae evry (hs Yea Gee of 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: [P50 
2. Total hours (MH-60S) : (OOO 


3. Previous model qualified HAC?: flo 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 


(SAR, LOG, MEDEVAC, etc): 


SAK f WDEVAL / Loos, AM jp TacTZeS 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 


Acu for Fite ~- Grnller is orl Fo monifulole 
Muar 11700 ja lee bully af Ske as bell, Lo 


Ih G 2° Aaded job Only on lel side Moke 
hore tthe. “bax Garnller 


3. What are your general likes and dislikes with the 


cockpit interface? 


bikes: Cofy [@ealaat- bar trches turns 


3 


88 





Dislikes: 


2 Feat Carre lles— 
- VRE 


~ Mo Powis Va? ; 
spall REMI Cord Capac t/ 
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- Aa de ét 


4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 
= Moving Me) is fle Meyt Gls Cor 
nw dhe Orn MRL / 2 4 
ing ? Be: J CRS re ‘is ae 
_ Da fegeotee” 
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5. Finally, if there was something you could change 


about the cockpit, what would it be? ; 
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Pp 


dine. ooh! or Vas Cae Fyfe 


II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: [So 
2. Total hours (MH-60S): [000 


3. Previous model qualified HAC?: No 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 


(SAR, LOG, Meld etc): 


Armeel Helo Faas (ment) sar, AVAME 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 


_ [urder yn Mnejeta Ge not Peock ble bn the. lores 
~ FR cls ley too ove lf Sbostel &¢ berg 2/- picture 
irth bebe Sef ofoh ur 

ie Le te fou Fevepee by ae, 
(ATs 


cockpit interface? 
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~ Vispleg Si ey weston at nwt s led- fo. on 
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3. What are your general likes and dislikes with the 
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4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 
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5. Finally, if there was something you could change 


about the cockpit, what would it be? 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: |37O 


2. Total hours (MH-60S): J6D bo 


3. Previous model qualified HAC?: F/H 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 


(SAR, LOG, MEDEVAC, etc): 


Hrmed! Helo 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: | 
Lier Use FLT ad efor deehps (weapons ,€ — 
yyst Got LFece mele ,; ge da Brel Carter! , (Carn e; 
Sore amt torn off al} Paer A Syifen Oe 
cpible. Hen Cobley ty Peimvertory Stores onl eft 

/ 


He. proces - dre br satety 


What are your general likes and dislikes with the 


cockpit interface? 


Likes: 
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4. Are there any other MH-60S interface issues that you 

would like to describe or may be relevant to this study? 
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5. Finally, if there was something you could change 


about the cockpit, what would it be? S / 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: 1ysO 
2. Total hours (MH-608): (2OO 


3. Previous model qualified HAC?: bo 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 
(SAR, LOG, MEDEVAC, etc): 


SAL, Loe j MaAtoPs 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting ra missions: 


2 AR - Cow) jled Hover DH tS rok weel do Sed ‘A ( Ep 
OAR saved Cor inv Lal paevon: a 
~Lhy at & {l feed 5S Aru rel fot Megrel ould 


be in OSH 
~ (per cae 


cockpit interface? 


Legal | low ne rele BR pel 


t are ale general likes and dislikes with the 


Likes: 
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Dislikes: 
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4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 
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5. Finally, if there was something you could change 


about the cockpit, what would it be? 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


O 
1. Total hours: ($50 Iss 
2. Total hours (MH-60S): 


3. Previous model qualified HAC?: No 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 
(SAR, LOG, MEDEVAC, etc): 
Awed FLO J ovéhowy (Ter) , fer, SAK 
CEe= Tage ol COClS 2 sereen — tsdeoe/ 
- Gy an lepesy stem (Ht-to# Sam 
{ 


oj 


ob cnlve = Serre 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 
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\r har 4 [oyes — . SA 
: is frm ifyree byerl 0 clus hy byes ie hee 
3) 


What are your general likes and dislikes with the 


cockpit interface? 


Likes: 
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4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 
FLTR Conga ey fo sawed 7 bigger Soo 
Lull be Caner pA Ont fer setS, 


5. Finally, if there was something you could change 


about the cockpit, what would it be? 


‘ircet baler ayrew to See All Clr 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


{p00 


1. Total hours: 





2. Total hours (MH-60S): [000 


3. Previous model qualified HAC?: fe 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 


(SAR, LOG, MEDEVAC, etc): 


Lol, SAR, FAs, MUD Mite, "tien tig 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 
conducting those missions: 


DRE. MO fs TA Input Slows Chan optratons 
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3. What are your general likes and dislikes with the 


cockpit interface? 


Likes: 7 Delo i _ 
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an cyeltc 
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Dislikes: Tee /oretion * bod Star pane 
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4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 


Axed YE Pocbo 


5. Finally, if there was something you could change 


about the cockpit, what would it be? 


Neel defer Ue dslety ote ale 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: (202 


2. Total hours (MH-608): 32 


3. Previous model qualified HAC?: [t-Go FH 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 
(SAR, LOG, MEDEVAC, etc): 


fan | Areed He/o 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 
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3. What are your general likes and dislikes with the 


cockpit interface? 


Likes: 


poe Fume opliet” Dayle TY, Color 
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Dislikes: | jes 
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4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 
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5. Finally, if there was something you could change 


about the cockpit, what would it be? 
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II. INTERVIEW DATA COLLECTION 


A. FLIGHT EXPEREINCE 


1. Total hours: [S00 
2. Total hours (MH-60S): FOO 


3. Previous model qualified HAC?: Re 
B. QUESTIONS 


1. What MH-60S missions are you most familiar with 
(SAR, LOG, MEDEVAC, etc): : 


SAR, LOC, Theres (Ared Heh 


2. Given you experience in the above missions you 
highlighted, tell me about instances for which you may have 
experienced difficulties with the cockpit interface while 


conducting those missions: 


Livin botrg 0 lows Boot up 10 baveat 
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3. What are your general likes and dislikes with the 


cockpit interface? 


Likes: 


\ 
see fe Cardo ling porter” 
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ee ‘ or Nepntly Vy ed stews. 


4. Are there any other MH-60S interface issues that you 


would like to describe or may be relevant to this study? 


~ free bowl disploy is gq Pas 


5. Finally, if there was something you could change 


about the cockpit, what would it be? 


_ Pe HO SCGES - uncom br tebe 
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